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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2006). 
Abstract 


This document defines a simple clear-text user/password Simple 
Authentication and Security Layer (SASL) mechanism called the PLAIN 
mechanism. The PLAIN mechanism is intended to be used, in 
combination with data confidentiality services provided by a lower 
layer, in protocols that lack a simple password authentication 
command. 
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Le 


Introduction 


Clear-text, multiple-use passwords are simple, interoperate with 
almost all existing operating system authentication databases, and 
are useful for a smooth transition to a more secure password-based 
authentication mechanism. The drawback is that they are unacceptable 
for use over network connections where data confidentiality is not 
ensured. 


This document defines the PLAIN Simple Authentication and Security 
Layer ([SASL]) mechanism for use in protocols with no clear-text 
login command (e.g., [ACAP] or [SMTP-AUTH]). This document updates 
RFC 2595, replacing Section 6. Changes since RFC 2595 are detailed 
in Appendix A. 


The name associated with this mechanism is "PLAIN". 
The PLAIN SASL mechanism does not provide a security layer. 


The PLAIN mechanism should not be used without adequate data security 
protection as this mechanism affords no integrity or confidentiality 
protections itself. The mechanism is intended to be used with data 
security protections provided by application-layer protocol, 
generally through its use of Transport Layer Security ([TLS]) 
services. 


By default, implementations SHOULD advertise and make use of the 
PLAIN mechanism only when adequate data security services are in 
place. Specifications for IETF protocols that indicate that this 
mechanism is an applicable authentication mechanism MUST mandate that 
implementations support an strong data security service, such as TLS. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [Keywords]. 


PLAIN SASL Mechanism 


The mechanism consists of a single message, a string of [UTF-8] 
encoded [Unicode] characters, from the client to the server. The 
client presents the authorization identity (identity to act as), 
followed by a NUL (U+0000) character, followed by the authentication 
identity (identity whose password will be used), followed by a NUL 
(U+0000) character, followed by the clear-text password. As with 
other SASL mechanisms, the client does not provide an authorization 
identity when it wishes the server to derive an identity from the 
credentials and use that as the authorization identity. 
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The formal grammar for the client message using Augmented BNF [ABNF] 
follows. 


message = [authzid] UTF8NUL authcid UTF8NUL passwd 
authcid = 1*SAFE ; MUST accept up to 255 octets 
authzid = 1*SAFE ; MUST accept up to 255 octets 
passwd = 1*SAFE ; MUST accept up to 255 octets 
UTF8NUL = $x00 ; UTF-8 encoded NUL character 

SAFE = UTF1 / UTF2 / UTF3 / UTF4 


7; any UTF-8 encoded Unicode character except NUL 


UTF1 = %x01-7F ;; except NUL 

UTF2 = $xC2-DF UTFO 

UTF3 = %xE0 %xAO-BF UTFO / %xE1-EC 2(UTFO) / 
SxED %x80-9F UTFO / %xEE-EF 2 (UTFO) 

UTF4 = $xFO %x90-BF 2(UTFO) / %xF1-F3 3(UTFO) / 
SxF4 %x80-8F 2(UTFO) 

UTFO = $x80-BF 


The authorization identity (authzid), authentication identity 
(authcid), password (passwd), and NUL character deliminators SHALL be 
transferred as [UTF-8] encoded strings of [Unicode] characters. As 
the NUL (U+0000) character is used as a deliminator, the NUL (U+0000) 
character MUST NOT appear in authzid, authcid, or passwd productions. 


The form of the authzid production is specific to the application- 
level protocol’s SASL profile [SASL]. The authcid and passwd 
productions are form-free. Use of non-visible characters or 
characters that a user may be unable to enter on some keyboards is 
discouraged. 


Servers MUST be capable of accepting authzid, authcid, and passwd 
productions up to and including 255 octets. It is noted that the 
UTF-8 encoding of a Unicode character may be as long as 4 octets. 


Upon receipt of the message, the server will verify the presented (in 
the message) authentication identity (authcid) and password (passwd) 
with the system authentication database, and it will verify that the 
authentication credentials permit the client to act as the (presented 
or derived) authorization identity (authzid). If both steps succeed, 
the user is authenticated. 


The presented authentication identity and password strings, as well 
as the database authentication identity and password strings, are to 
be prepared before being used in the verification process. The 
[SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED 
preparation algorithm. The SASLprep preparation algorithm is 
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recommended to improve the likelihood that comparisons behave in an 
expected manner. The SASLprep preparation algorithm is not mandatory 
so as to allow the server to employ other preparation algorithms 
(including none) when appropriate. For instance, use of a different 
preparation algorithm may be necessary for the server to interoperate 
with an external system. 


When preparing the presented strings using [SASLPrep], the presented 
strings are to be treated as "query" strings (Section 7 of 
[StringPrep]) and hence unassigned code points are allowed to appear 
in their prepared output. When preparing the database strings using 
[SASLPrep], the database strings are to be treated as "stored" 
strings (Section 7 of [StringPrep]) and hence unassigned code points 
are prohibited from appearing in their prepared output. 


Regardless of the preparation algorithm used, if the output of a 
non-invertible function (e.g., hash) of the expected string is 
stored, the string MUST be prepared before input to that function. 


Regardless of the preparation algorithm used, if preparation fails or 
results in an empty string, verification SHALL fail. 


When no authorization identity is provided, the server derives an 
authorization identity from the prepared representation of the 
provided authentication identity string. This ensures that the 
derivation of different representations of the authentication 
identity produces the same authorization identity. 


The server MAY use the credentials to initialize any new 
authentication database, such as one suitable for [CRAM-MD5] or 
[DIGEST-MD5]. 


3.  Pseudo-Code 
This section provides pseudo-code illustrating the verification 
process (using hashed passwords and the SASLprep preparation 


function) discussed above. This section is not definitive. 


boolean Verify(string authzid, string authcid, string passwd) { 
string pAuthcid = SASLprep(authcid, true); # prepare authcid 


string pPasswd = SASLprep(passwd, true); # prepare passwd 
if (pAuthcid == NULL || pPasswd == NULL) { 
return false; # preparation failed 
} 
if (pAuthcid == ™" | | pPasswd == "") { 
return false; # empty prepared string 


} 
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storedHash = FetchPasswordHash (pAuthcid) ; 


if (storedHash == NULL || storedHash == "") { 
return false; # error or unknown authcid 
} 
if (!Compare(storedHash, Hash(pPasswd))) { 
return false; # incorrect password 
} 
if (authzid == NULL ) { 
authzid = DeriveAuthzid(pAuthcid) ; 
if (authzid == NULL || authzid == "") 4 


return false; # could not derive authzid 


} 


if (!Authorize(pAuthcid, authzid)) { 
return false; # not authorized 


return true; 


} 


The second parameter of the SASLprep function, when true, indicates 
that unassigned code points are allowed in the input. When the 
SASLprep function is called to prepare the password prior to 
computing the stored hash, the second parameter would be false. 


The second parameter provided to the Authorize function is not 
prepared by this code. The application-level SASL profile should be 
consulted to determine what, if any, preparation is necessary. 


Note that the DeriveAuthzid and Authorize functions (whether 
implemented as one function or two, whether designed in a manner in 
which these functions or whether the mechanism implementation can be 
reused elsewhere) require knowledge and understanding of mechanism 
and the application-level protocol specification and/or 
implementation details to implement. 


Note that the Authorize function outcome is clearly dependent on 
details of the local authorization model and policy. Both functions 
may be dependent on other factors as well. 
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4. 


Examples 


This section provides examples of PLAIN authentication exchanges. 
The examples are intended to help the readers understand the above 


text. The examples are not definitive. 

"C:" and "S:" indicate lines sent by the client and server, 
respectively. "<NUL>" represents a single NUL (U+0000) character. 
The Application Configuration Access Protocol ([ACAP]) is used in the 
examples. 


The first example shows how the PLAIN mechanism might be used for 
user authentication. 


S: * ACAP (SASL "CRAM-MD5") (STARTTLS) 

C: a001 STARTTLS 

S: a001 OK "Begin TLS negotiation now" 

<TLS negotiation, further commands are under TLS layer> 
S: * ACAP (SASL "CRAM-MD5" "PLAIN") 
C: a002 AUTHENTICATE "PLAIN" 

S: + wi 

Cre 424-4 

C: <NUL>tim<NUL>tanstaaftanstaaf 

S: a002 OK "Authenticated" 


The second example shows how the PLAIN mechanism might be used to 
attempt to assume the identity of another user. In this example, the 
server rejects the request. Also, this example makes use of the 
protocol optional initial response capability to eliminate a round- 
EFip.. 


S: * ACAP (SASL "CRAM-MD5") (STARTTLS) 

C: a001 STARTTLS 

S: a001 OK "Begin TLS negotiation now" 

<TLS negotiation, further commands are under TLS layer> 

S: * ACAP (SASL "CRAM-MD5" "PLAIN") 

C: a002 AUTHENTICATE "PLAIN" {20+} 

C: Ursel<NUL>Kurt<NUL>xipj3plmq 

S: a002 NO "Not authorized to requested authorization identity" 


Security Considerations 


As the PLAIN mechanism itself provided no integrity or 
confidentiality protections, it should not be used without adequate 
external data security protection, such as TLS services provided by 
many application-layer protocols. By default, implementations SHOULD 
NOT advertise and SHOULD NOT make use of the PLAIN mechanism unless 
adequate data security services are in place. 
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When the PLAIN mechanism is used, the server gains the ability to 
impersonate the user to all services with the same password 
regardless of any encryption provided by TLS or other confidentiality 
protection mechanisms. Whereas many other authentication mechanisms 
have similar weaknesses, stronger SASL mechanisms address this issue. 
Clients are encouraged to have an operational mode where all 
mechanisms that are likely to reveal the user’s password to the 
server are disabled. 


General [SASL] security considerations apply to this mechanism. 


Unicode, [UTF-8], and [StringPrep] security considerations also 
apply. 


6. IANA Considerations 


The SASL Mechanism registry [IANA-SASL] entry for the PLAIN mechanism 
has been updated by the IANA to reflect that this document now 
provides its technical specification. 


To: iana@iana.org 
Subject: Updated Registration of SASL mechanism PLAIN 


SASL mechanism name: PLAIN 

Security considerations: See RFC 4616. 

Published specification (optional, recommended): RFC 4616 

Person & email address to contact for further information: 
Kurt Zeilenga <kurt@openldap.org> 
IETF SASL WG <ietf-sasl@imc.org> 

Intended usage: COMMON 

Author/Change controller: IESG <iesg@ietf.org> 

Note: Updates existing entry for PLAIN 
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Appendix A. Changes since RFC 2595 
This appendix is non-normative. 
This document replaces Section 6 of RFC 2595. 


The specification details how the server is to compare client- 
provided character strings with stored character strings. 


The ABNF grammar was updated. In particular, the grammar now allows 
LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the 
authzid, authcid, passwd productions. However, whether these control 
characters may be used depends on the string preparation rules 
applicable to the production. For passwd and authcid productions, 
control characters are prohibited. For authzid, one must consult the 
application-level SASL profile. This change allows PLAIN to carry 
all possible authorization identity strings allowed in SASL. 


Pseudo-code was added. 


The example section was expanded to illustrate more features of the 
PLAIN mechanism. 
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